System and method for forecasting the composition of an outbound train in a switchyard

ABSTRACT

A system for forecasting the outbound workload in a switchyard. The system has a processing entity for which receives information on railcar traffic for handling by the switchyard, wherein the railcar traffic includes railcars that are yet to be switched into classification tracks of the switchyard. For every departure train of two or more departure trains, the processing entity applies logic rules to the information to compute a forecast of railcar traffic that will be available to the departure train for transport out of the switchyard. An output releases data derived from the forecast of railcar traffic, describing the traffic available for each train of the two or more departure trains.

CROSS-REFERENCE TO RELATED APPLICATION

The present application is a continuation-in-part of prior U.S.application Ser. No. 11/601,338 filed on Nov. 17, 2006. The contents ofthe aforementioned document are incorporated by reference herein.

This application is also a continuation-in-part application claiming thebenefit of priority under 35 USC §120 of U.S. patent application Ser.No. 11/387,347 filed Mar. 23, 2006 by Kari Muinonen et al., andpresently pending, which claims the benefit of priority on U.S.provisional application Ser. 60/754,601 filed Dec. 30, 2005, nowabandoned. The contents of the above-mentioned patent application areincorporated herein by reference.

FIELD OF THE INVENTION

The invention relates to a process for managing operations in a railroadswitchyard. The invention also encompasses a technological platform andindividual components thereof to implement the process.

BACKGROUND OF THE INVENTION

A railroad network normally contains one or more switchyards in whichrailcars are routed from tracks leading from a departure point to tracksgoing to a destination point. A typical switchyard has four maincomponents, namely receiving tracks, a railcar switching mechanism, aset of classification tracks and a set of departure tracks. Incomingtrains deliver railcars in the receiving tracks. The railcars areprocessed by the switching mechanism that routes individual railcars torespective classification tracks.

Two types of switching mechanisms are in use today. The first one is ahump switch. Switchyards that use a hump switch are referred to as humpyards. A hump switchyard uses a hump over which a railcar is pushed by alocomotive. At the top of the hump the railcar is allowed to roll on theother side of the hump under the effect of gravity. Retarders keep therailcar from reaching excessive speeds. The hump tracks on which therailcar rolls down the hump connect with the classification tracks. Atrack switch establishes a temporary connection between the hump tracksand a selected one of the classification tracks such that the railcarcan roll in the classification tracks. A departure train is constitutedwhen the requisite number of railcars has been placed in a set ofclassification tracks. When the departure train leaves the switchyard,the set of classification tracks become available for building a newdeparture train.

The second type of switch mechanism is a flat switch. The principle isgenerally the same as a hump yard except that instead of using gravityto direct railcars to selected classification tracks, a locomotive isused to push the railcar from the receiving tracks to the selected setof classification tracks.

In order to increase the efficiency of switching operations railwaycompanies have developed the concept of railcar blocking. Under thisconcept, a block of railcars, hence the name “blocking”, may belogically switched as a unit in a switchyard. A block is established ona basis of certain properties shared by the railcars belonging to theblock. For instance railcars that have a common destination point ontheir route can be blocked together. A “block” is therefore a logicalentity that helps making switching decisions. For reference it should benoted that generally, two types of blocks exist. There is the so called“yard block” and a “train block”. For clarity, the term “block” alone inthe present specification encompasses either a yard block or a trainblock.

The principle of blocking, either yard blocking or train blockingincreases the efficiency with which railcars are processed atswitchyards. However, it also brings constraints. Very often a trainblock must be assembled from railcars that arrive on different incomingtrains. The train block will be complete and available for departureonly when all the railcars that make up the train block have arrived atthe switchyard. If one or more of the railcars are delayed the trainblock cannot be completed and the entire departure train that pulls thistrain block may leave without the delayed railcars. Such occurrence maycreate a cascading effect throughout entire segments of the railroadnetwork and have significant financial repercussions for the railroadoperator. Specifically, it is not uncommon for an operator to guaranteerailcar arrival times to customers and delays incur financial penaltiesthat may be significant.

In general switchyard operations planning is done either manually or viasimple management tools. In order to increase the efficiency of thoseoperations there is a need to provide an automated system that canforecast the outbound workload and thus provide the yard master with aprojection of the traffic that can be available to departure trains.

SUMMARY OF THE INVENTION

As embodied and broadly described herein, the invention includes asystem for forecasting the outbound workload in a switchyard. The systemhas a processing entity for which receives information on railcartraffic for handling by the switchyard, wherein the railcar trafficincludes railcars that are yet to be switched into classification tracksof the switchyard. For every departure train of two or more departuretrains, the processing entity applies logic rules to the information tocompute a forecast of railcar traffic that will be available to thedeparture train for transport out of the switchyard. An output releasesdata derived from the forecast of railcar traffic, describing thetraffic available for each train of the two or more departure trains.

As embodied and broadly described herein, the invention also provides amethod for forecasting the outbound workload in a switchyard. The methodcomprises the step of receiving information on railcar traffic forhandling by the switchyard, wherein the railcar traffic includesrailcars that are yet to be switched into classification tracks of theswitchyard. The method also includes the steps of, for each of two ormore departure trains, applying logic rules to the information tocompute a forecast of railcar traffic that will be available to thedeparture train for transport out of the switchyard, and releasing dataderived from the forecast of railcar traffic, for describing to a userthe traffic available for each train of the two or more departuretrains.

As embodied and broadly described herein, the invention further includesa system for forecasting the outbound workload in a switchyard. Thesystem comprises a processing entity for:

-   -   i) assigning railcars that have not yet been switched into        classification tracks of the switchyard to respective departure        trains; and    -   ii) computing a forecast of railcar traffic that will be        available to individual ones of the departure trains for        transport out of the switchyard at least in part on the basis of        said assigning;    -   b) an output for releasing data derived from the forecast of        railcar traffic, describing the traffic available for at least        one of the departure trains.

As embodied and broadly described herein, the invention further includesa method for forecasting the outbound workload in a switchyard. Themethod includes:

-   -   a) assigning railcars that have not yet been switched into        classification tracks of the switchyard to respective departure        trains;    -   b) computing with a computer a forecast of railcar traffic that        will be available to individual ones of the departure trains for        transport out of the switchyard at least in part on the basis of        the assigning;    -   c) releasing data from the computer derived from the forecast of        railcar traffic, describing the traffic available for at least        one of the departure trains.

As embodied and broadly described herein, the invention further includesa system for forecasting the outbound workload in a switchyard. Thesystem includes:

-   -   a) a processing entity for:        -   i) matching railcars yet to be switched in the switchyard to            departure trains, said matching including forecasting for a            railcar the departure train that will be available to            transport the railcar out of the switchyard when the            processing of the railcar by the switchyard will be            completed;        -   ii) computing a forecast of railcar traffic that will be            available to individual ones of the departure trains for            transport out of the switchyard at least in part on the            basis of said matching;    -   b) an output for releasing data derived from the forecast of        railcar traffic, describing the traffic available for at least        one of the departure trains.

BRIEF DESCRIPTION OF THE DRAWINGS

A detailed description of examples of implementation of the presentinvention is provided hereinbelow with reference to the followingdrawings, in which:

FIG. 1 is a schematical illustration of a hump switchyard;

FIG. 2 is a high level block diagram of a prior art computer basedswitchyard management system;

FIG. 3 is a high level block diagram of a computer based switchyardmanagement system according to a non-limiting example of implementationof the invention;

FIG. 4 is a more detailed block diagram of the system shown in FIG. 3;and

FIG. 5 is a flowchart of a process for identifying a preferred sequencein which railcars are to be switched at the switchyard; and

FIG. 6 is a more detailed flowchart of the process shown in FIG. 5;

FIG. 7 is a functional block diagram of an outbound workflow forecastingmodule;

FIG. 8 is a flowchart of a process implemented by the workflowforecasting module shown in FIG. 7;

FIG. 9 is an excerpt of GUI illustrating the workflow forecastinginformation at the train level;

FIG. 10 is an excerpt of a GUI illustrating the workflow forecastinginformation at the block level;

FIG. 11 is an excerpt of a GUI illustrating the workflow forecastinginformation at the track level;

FIG. 12 is an excerpt of a GUI illustrating the workflow forecastinginformation at the location level;

FIG. 13 is an excerpt of a GUI illustrating the workflow forecastinginformation at the railcar level;

FIG. 14 is an excerpt of a GUI illustrating the workflow forecastinginformation at the block level with editable fields highlighted allowingto manually adjust blocks settings;

FIG. 15 is an excerpt of a GUI illustrating a limit calculator screen;and

In the drawings, embodiments of the invention are illustrated by way ofexample. It is to be expressly understood that the description anddrawings are only for purposes of illustration and as an aid tounderstanding, and are not intended to be a definition of the limits ofthe invention.

DETAILED DESCRIPTION

FIG. 1 is an illustration of a hump switching yard in which themanagement process of the invention can be implemented. The humpswitching yard 10 has four main components namely receiving tracks 12, ahump 14, classification tracks 16 and departure tracks 17. The receivingtracks 12 include railway sections in which an incoming train deliversrailcars to be switched.

The receiving tracks 12 lead to the hump 14. The hump 14 includes a setof tracks 20 that lead to the hump crest 18 that is the highestelevation of the hump 14. railcars are pushed by a locomotive on thetracks 20 up to the hump crest 18 at which point the railcar rolls downthe hump 14 by gravity toward the set of classification tracks 16. Therailcar passes through retarders 22 that will reduce its speed allowingit to gently coast in anyone of the selected classification tracks 16. Atrack switch 24, located downstream the retarders 22 temporarilyconnects the hump track 12 to a selected one of the classificationtracks 16 such as to direct the railcar to the desired classificationtrack 16.

The receiving tracks 12, therefore, form a switching queue in whichrailcars that are delivered to the switching yard 10, await to beswitched.

The classification tracks 16 lead to the departure tracks 17.Specifically, the classification tracks are arranged into groups, whereeach group leads to a departure track 17. The hump switchyard 10 shownin the drawings includes 10 classification tracks organized into twogroups of five tracks. Each group of five tracks connects to thedeparture track 17.

Generally, the classification tracks 16 are used to assemble trainblocks. Train blocks are pulled out of the classification tracks intothe departure tracks 17 where the actual departure train is built. Thedeparture tracks 17 allow assembling trains having more railcars than asingle classification track can hold. When a complete train (shorttrain) is assembled into a single classification track 16, the departuretrain leaves that track directly by passing through the departure track17.

It should be appreciated that FIG. 1 is a very simplified illustrationof a hump switchyard in that the number of tracks shown has beensignificantly reduced for clarity purposes. An average size hump yardtypically contains many more classification tracks than what is shown inFIG. 1. For example it would not be uncommon for a switchyard to have 80or more classification tracks organized into physical groups of tracks,where each group connects to a departure track. In addition, there willnormally be a larger number of departure tracks 17 than what appears onthe drawing.

The hump switchyard 10 also includes a reswitching track that allows to“recirculate” railcars from a position downstream of the switch 24 to aposition upstream of the switch 24. In a typical hump switchyard, suchas the yard 10 the reswitching track is called “rehump track”. Therehump track is shown at 26 in FIG. 1. The rehump track 26 originatesdownstream the track switch 24 leads to the hump tracks 20 at the baseof the hump 14. The purpose of the rehump tracks 26 is to provide abuffering mechanism where one or more railcars can be temporarily put instorage without blocking the flow of other railcars through the humpswitchyard 10. For instance, situations may arise where one or morerailcars in the receiving tracks 12 cannot be switched in any one of theclassification tracks 16. This may be due, for example to the lack ofspace availability in the classification tracks 16. It is commonpractice for a hump switchyard 10 to periodically hump the railcars inthe rehump tracks 26. Such rehumping involves pushing the railcars overthe hump 14 such that they can be switched to a selected classificationtrack 16. If a railcar cannot be routed to any one of the classificationtracks 16 it is put back in the rehump tracks 26 for a new humpingcycle.

The following description of a non-limiting example of implementation ofa switchyard management process will be done in connection with a humpswitchyard 10 of the type described earlier. However, it should beexpressly noted that the principles of the invention apply equally wellto a flat switchyard. Accordingly, the invention should not be limitedto a hump switchyard but encompasses a flat switchyard as well. A flatswitchyard operates generally in the same way as described earlier inthat incoming trains deliver railcars at the input side of the flatswitchyard, a switching device routes the individual railcars toclassification tracks to assemble departure trains in departure tracks.

FIG. 2 illustrates a block diagram of a prior art control system 28 foruse in managing the operations of a hump switchyard 10. Specifically,the control system 28 includes two main components, namely the ServiceReliability System (SRS) component 30 and the Hump Process ControlSystem (HPCS) 32. The SRS component 30 is in essence a railway trafficmanagement system that keeps track of the rolling stock inventorythroughout the rail network. It is used to manage the flow of railwaytraffic over a complete railway network or a portion thereof. The SRScomponent 30 is a computer based system that reflects the railwayoperations by showing information on trains, schedules, waybills, tripplans and train delays. The SRS component 30 has a number of sub-systemsthat are integrated to one another. Some of the sub-components arebriefly described below:

-   -   Waybill—a computer file that provides details and instructions        on the movement of railcars railcars and units cannot move        without a waybill;    -   Service Scheduling—the service scheduling sub-component is based        on a trip plan that specifies the events a shipment must follow        from origin to destination. A trip plan identifies the train        connections for each railcar and provides a destination        Estimated Time of Arrival (ETA). The service scheduling        sub-component continuously monitors the movement of each        shipment and compares its progress to the trip plan. If the        service scheduling determines that a shipment will not meet the        established requirements, it triggers alarms;    -   Yard Operating Plan/Daily Operating Plan (YOP/DOP)—the YOP        sub-component defines how assets (crews, railcars, locomotives        and tracks) are allocated to support yard related activities.        The DOP is derived from the YOP and contains instructions for        industrial assignments;    -   Yard, Industry and Train (YIT)—the YIT sub-component allows        users to report train and railcar movements such as train        arrivals and departures, yard switches, exchange of railcars        with other railroads, and the placing and pulling of railcars at        a customer siding.    -   Intermodal—this sub-component includes functions for gating-in,        gating-out, assigning, ramping, de-ramping as well as        maintaining inventories of Intermodal equipment.

The SRS component 30 includes a processing function that is illustratedas a single block, but it can be implemented also in a distributedfashion.

It should be expressly noted that the SRS component 30 is merely anexample of a railway traffic management system and other railway trafficmanagement systems can be used without departing from the spirit of theinvention.

The HPCS component 32 operates the track switch in the hump switchyard10. Essentially, the HPCS component 32 is a railcar switch controlsystem that determines on the basis of inputs the position of the trackswitch 24 such that a railcar or a series of railcars over the hump,will be directed to the desired classification track 16. Broadly stated,the HPCS component 32 has two main goals, namely:

-   -   Deliver the railcars to the correct classification track 16;    -   Insure that the railcars will arrive in the classification track        16 fast enough to reach the railcars already in the track but        slow enough for a safe coupling (or reach the far end of the        track if it is empty);

As in the case with the SRS component 30, the HPCS component 32 isillustrated as a single block but it can be implemented in a distributedfashion.

It should be expressly noted that the HPCS component 32 is merely anexample of a railcar switch control system and other railcar switchcontrol systems can be used without departing from the spirit of theinvention.

As shown by FIG. 2 a human intervention 34 is required to interface theSRS component 30 and the HPCS component 32. Specifically, the SRScomponent identifies the trains that are scheduled to arrive at the humpswitchyard 10 and the trains that are scheduled to depart the humpswitchyard 10. On the basis of this information a hump list is manuallyproduced. The hump list determines in which classification track thevarious railcars will go. The hump list is then loaded into the HPCScomponent 32. The HPCS component 32 performs the switching as therailcars are humped, according to the specific switching instructions inthe hump list. As indicated previously, the prior art technique consistsof humping the railcars according to a FIFO sequence; the railcars thatarrive first at the switchyard are likely to be humped first, unless theyard operator decides otherwise. In short the humping operation islargely driven by human judgment and its efficiency is thereforedependent on the experience and knowledge of the operator. In addition,the number of factors that the operator needs to take into account inorder to make a decision on the order in which the railcars are to behumped is quite large which makes it very difficult to mentally figurewhat the optimal solution is.

Note the communication link 35 between the HPCS component 32 and the SRScomponent 30. This link 35 illustrates the exchange of data between thetwo components, for instance the HPCS component 32 notifying the SRScomponent 30 of events or conditions occurring in the hump switchyard10.

FIG. 3 is a block diagram of control system 44 for use in managing theoperations of the hump switchyard 10, according to a non-limitingexample of implementation of the invention. The control system 44includes three main components two of which are shared with the priorart control system 28 described earlier. Specifically, the controlsystem 44 includes the SRS component 30, the HPCS component 32 and anoperations management (OM) controller 46. The controller 46 isresponsible for operations in the pre-switching category, such as toidentify a preferred railcar switching sequence. It is also possible todesign the OM controller 46 to manage tasks in the post-switchingcategory, without departing from the spirit of the invention. Onespecific example of a post switching category task that the OMcontroller 46 can handle, is the allocation of switched railcars toclassification tracks 16.

FIG. 4 is a block diagram of the OM controller 46, showing therelationships with the SRS component 30 and the HPCS component 32. TheOM controller 46 has a computing platform including a processor 47 thatcommunicates with a machine readable storage unit 49, commonly referredto as “memory” over a data bus. Inputs and outputs (I/O interface) 51allow the OM controller 46 to receive and send data to the SRS component30 and the HPCS controller 32, via the SRS component 30. In addition,the I/O 51 communicates with a user interface 53 that allows the OMcontroller 46 to communicate information to the user and receivescommands or other inputs from the user. In essence, the user interface53 shows the user recommended hump sequences and switching (assumingthat the OM controller 46 is provided with functionality to handle theallocation of railcars to classification tracks 16) solutions that theOM controller 46 is developing. Those switching solutions can beimplemented either automatically, i.e. pending an input from the userthat stops the process, the proposed switching solutions are executed,or they may require explicit confirmation from the user. For instance,unless the user inputs at the user interface 53 a command to explicitlyimplement or authorize the switching solution presented by the OMcontroller 46 on the user interface 53, no action is taken by thesystem.

Note that while the diagram at FIG. 4 depicts the OM controller 46 as asingle unit, it can also have a distributed architecture withoutdeparting from the spirit of the invention.

The functionality of the OM controller 46 is software defined. In otherwords, the logic that computes preferred humping sequences and also thatdetermines how railcars are to be switched is implemented by executingsoftware by the processor 47. The software in the form of program codeis stored in the memory 49. The software reads data inputs received fromthe SRS component 30, and from the user interface 53. On the basis ofthose inputs, the OM controller 46 generates outputs to the userinterface 53. The output to the user interface 53 is intended to displayinformation to inform the user on the recommended hump sequences andswitching solutions the OM controller 46 has reached. Optionally, anoutput may also be directed to the HPCS component 32, which containsswitching commands that determine the positions of the track switch 24and effectively implement the switching solutions developed by the OMcontroller 46.

In the example illustrated in FIG. 4, the OM controller 46 logicallyresides between the SRS component 30 and the HPCS component 32. As suchthe OM controller 46 receives information from the SRS component 30about:

-   -   Incoming trains (trains to be received in the hump switchyard        10), in particular:        -   Identification of the train (Train ID)        -   The Expected Time of Arrival (ETA);        -   Point of origin;        -   Destination;        -   Identification of the train blocks that make up the train.    -   Departure trains (trains the switchyard 10 is expected to        assemble);        -   Identification of the train (Train ID;        -   The Expected Time of Departure (ETD);        -   Identification of the train blocks that make up the train.

In order to make hump sequence recommendations and classification trackassignments to individual railcars, the OM controller 46 createsrepresentations in the memory 49 of the rolling stock that transitsthrough the hump switchyard 10 by using hierarchal objects. Generally,three types of objects exist:

-   -   A train object. A train object is associated with each train        (arrival train or departure train) and it has properties such        as:        -   A train identifier (train ID);        -   Expected time of arrival (ETA);        -   Origin;        -   Destination;        -   Route; and        -   Identification of train blocks that make up the train.    -   A train block object. A train block object is associated with a        block of railcars and has the following properties:        -   A train block identifier (train block ID);        -   Number of railcars making up the train block;        -   Identity of the railcars making up the train block;        -   Destination of the train block; and        -   Route of the train block from the origin to the destination.    -   A yard block object. A yard block object is associated with a        block of railcars and has the following properties:        -   A yard block identifier (yard block ID);        -   Number of railcars making up the yard block;        -   Identity of the railcars making up the yard block;        -   Origin of the yard block;        -   Destination of the yard block; and        -   Route of the yard block from the origin to the destination.    -   Car objects. A railcar object is associated with a single        railcar and has the following properties:        -   Car identifier (car ID);        -   Car owner;        -   If railcar railcarries railcargo the type of railcargo;        -   If railcar is empty the customer identifier that has            requested the railcar to be moved;        -   Origin;        -   Destination; and        -   Route between origin and destination.

Normally, train objects that represent incoming trains will cease toexist when the train arrives at the hump switchyard 10 since the trainis dismantled. An exception to this is a situation where the incomingtrain transits through the hump switchyard 10 in which case it remainsintact. Departure trains are represented by train objects that begintheir existence at the hump switchyard 10, having been assembled fromrailcars that originate from one or more dismantled incoming trains.Incoming train block objects may cease to exist if the train block isdisassembled and the individual railcars are used to make up other trainblock objects. For example a train block arriving at the hump switchyard10 may contain railcars having different destinations. For the sake ofthis example, say that half of the railcars need to be delivered to cityA while the other half to city B. In such case the train block isdisassembled and the railcars that go to city A are switched to form,alone or in combination with other railcars from a different train, anew train block that will travel to city A. The railcars directed tocity B are switched in a similar manner. In this situation, two newtrain blocks are created at the hump switchyard 10, from one or moreincoming train blocks. Another possibility is for train blocks to bemodified, instead of ceasing to exist or beginning to exist. A trainblock can be modified by augmenting the train block, such as by addingto it one or more railcars or diminished by removing from it one or morerailcars. Finally, a train block may remain unchanged such as when itsimply transits through the hump switchyard 10. In such case, the trainblock is physically dismantled into individual railcars but theswitching operation is conducted such as to reassemble the originaltrain block. Alternatively, the train block can be routed directly tothe departure tracks 17 such as to circumvent the switch 24.

As far as individual railcar objects, they remain unchanged as theytransit through the hump switchyard 10.

The OM controller 46 receives from the SRS component 30 data thatdescribes the incoming trains so that the OM controller 46 can determinethe details of the rolling stock to be processed. The OM controller 46also receives information on the departure trains that the humpswitchyard 10 is expected to assemble.

In a specific example of implementation, the OM controller 46 receivesform the SRS component 30 the following information:

-   -   The trains scheduled to arrive to the hump switchyard 10. The        SRS component 30 simply provides the identity of the train (the        train ID);    -   The trains that the SRS system expects the hump switchyard to        make. The SRS component simply provides the identity of the        train (train ID).

Once the OM controller 46 is made aware of incoming trains and therequirement to build departure trains, the train ID information allowsthe OM controller 46 to determine all the necessary information down tothe individual railcar. More particularly, the train ID allowsdetermining the properties of the train object and the properties of thetrain block objects derived via the train object and the properties ofthe railcar objects derived via the train block objects. This data willthen allow the OM controller 46 to compute switching solutions.

It should be expressly noted that the above description of the manner inwhich information is provided to the OM controller 46 is strictly anexample and should not be constructed in any limiting manner. Manydifferent ways to deliver information to the OM controller 46 exist thatallow characterizing the incoming trains and the departure trainswithout departing from the spirit of the invention.

A detailed example of a recommended hump sequence computation by the OMcontroller 46 will be described below in conjunction with the processflowchart in FIGS. 5 and 6.

The flowchart at FIG. 5 illustrates generally the steps of an example ofthe process for finding a preferred switching sequence of railcars. Forthe purpose of the following description note that the expressions“humping sequence” and “switching sequence” may be used to designate thesame or similar process but the expressions have a different scope.“Humping sequence” refers to a sequence of railcars processed in a humpswitchyard, such as the one shown at FIG. 1. “Switching sequence” on theother hand is more general and refers to a sequence of railcars to beprocessed either in a flat switchyard or in a hump switchyard.

The process includes a start step 500 that is followed by step 502during which a number of possible sequences in which the railcar cutscan be switched. For example, if three railcar cuts exist, say cut 1,cut 2 and cut 3, a first switching sequence may be cut 1, cut 2 and cut3, a second possible switching sequence can be cut 2, cut 1 and cut 3, athird possible switching sequence can be cut 3, cut 2 and cut 1, etc.While it is possible at this stage to determine all possible sequencesof cuts this is not an absolute requirement. In fact, for large numberof cuts that exist in the switching queue and await switching, thedetermination of all the possible permutations may lead at the next stepof the process that is described below to a heavy computational burden,which may not be required in practice. Generally, the number ofsequences that will be determined in order to find a preferred sequenceis dependent on the computational resources available. At least twosequences need to be available in order to choose a preferred one, butin most practical cases more sequences will be considered to make achoice.

At step 504 the cut sequences determined at the earlier step areevaluated and a preferred sequence is selected. By “preferred” is meanta sequence that offers an advantage over another sequence that is beingevaluated. What constitutes an advantage is a matter of choice anddependent on the specific application. For example, if the user of theswitchyard considers preferable to minimize the time railcars spent inthe switchyard, the metric that will be used to evaluate the sequencesand select the preferred one will be the dwell time of the railcars inthe switchyard. In such example, step 504 evaluates the differentsequences and selects the one that allows reducing the dwell time of therailcars in the switchyard.

In another possible example, the metric used to evaluate the sequencesis the number of missed connections. By “missed connection” is meantthat a railcar that was destined to be part of a departure train is notavailable when the train departs. In such case the sequences areevaluated on the basis of missed connections and a preferred sequence isselected.

In many cases, the metric that is being applied may be refined by makinga distinction between different types of railcars. For example one maywant to distinguish between loaded railcars which usually have acommitment in terms of delivery date or time to a customer versus emptyrailcars that have no such commitment. If such distinction is made, ahigher priority can be given to loaded railcars than to empty railcars.In the case of the “missed connection” metric, the computation could bedone in a way to provide more weight to loaded railcars than to emptyrailcars. In this fashion, the resulting switching sequence will tend tofavor loaded railcars such that they make their connections at theexpense of empty railcars.

The selection of preferred sequence among the sequences that are beingevaluated includes, in one specific example, the computation of aperformance status of the switchyard that would be reached for eachsequence. In other words, the process will compute a performance statusfor the switchyard for every sequence and then compare the performancestatuses to select the preferred sequence. In one example, when themetric to evaluate sequences is based or factors in railcar dwell time,the performance status of a given sequence can be expressed as a valuethat reflects the dwell time of all the railcars in the switchyard or asubset of those railcars. In the example where the metric is missedconnections (or alternatively successfully made connections) then theperformance status of a given sequence can be expressed as a value thatreflects the number of missed (or realized) connections with departuretrains.

At step 506 the results of the evaluation made at step 504 areadisplayed to a user. This is done to describe to the user the preferredsequence such that the user can use this recommendation into making afinal decision on what the switching sequence will be. The descriptionof the preferred sequence can be done in many different ways withoutdeparting from the spirit of the invention. For instance, the preferredsequence can be shown on the display of the user interface 53 alone orlisted with the other less preferred sequences to show the user possibleoptions.

A more detailed example of the process for selecting a switchingsequence will now be described in connection with FIG. 6. The algorithmon which the process of FIG. 6 is based determines a preferred sequencein which cuts should be humped in order to maximize a score based onrailcars making their train connections (in other words, reducing missedconnections), when departure trains and blocks of those trains havefixed capacities.

The process starts at 600. During this start step, the user will fix theorder of the first few cuts to be humped. The process will then considerthe remaining cuts and generate possible sequences of those cuts inorder to find a preferred sequence. The evaluation of the possiblesequences may be limited to a reasonable number according to thecomputational resources available.

The score for anyone of the given sequences to be evaluated is the totalof the score for all the railcars in the cut (without intent to be boundby any specific definition, in the railroad industry a “cut” refers toany number of railcars attached to be pulled by an engine). Generally,the score for a railcar depends on the objective departure train and thescenario train for that railcar and the departure times of these trains.

At step 602, the objective departure train for each railcar in the cutsbeing considered is determined. The objective departure train for arailcar is the one that the railcar should connect to based on theprocess standard in the switchyard. For example, that standard may beset such that railcars that arrive on an incoming train, that need to behumped, have a minimum of 8 hours to connect to departure trains. Thescheduled arrival time of the inbound train is used as the startingpoint for the connection standard, as long as the train arrived early orwithin 2 hours of its scheduled arrival. If the train is more than 2hours late, the actual arrival time is used. For trains that areenroute, the same logic is used. For instance, Expected Time of Arrival(ETA)+8 hours if the train is running more than 2 hours late otherwiseScheduled Time of Arrival (STA)+8 hours.

The information necessary to make the objective departure traindetermination for each railcar is made available from SRS 30 (Refer toFIGS. 3 and 4). Also note that since the OM 46 has access to informationon incoming trains, it can perform humping sequence optimization on cutsthat include railcars yet to arrive in the switchyard 10.

After the computation at step 602 is completed the results are stored inthe memory 49, such as for example as a list mapping the railcars totheir respective objective departure trains.

Step 604 determines the volume of railcars that are committed to thedeparture trains. This is done to assess what is the available space inthe departure trains for railcars yet to be switched. The volume ofrailcars already committed includes:

-   -   1. Cars located on the departure yard prior to departure of the        outbound train;    -   2. Cars located on the appropriate classification track, prior        to cut-off;    -   3. Cars specifically selected by the yard operator;    -   4. Cars placed in outbound status prior to the block-swap        cut-off standard (those railcars bypass the humping process).    -   Note: If there are filler blocks, then one cannot assume that        these railcars are committed to outbound trains, since space on        filler blocks depends on future arrivals of core block railcars        which in turn depends on the hump sequence.

At step 606 a hump sequence is generated. This is done mathematicallybased on the cuts that are to be evaluated. The following steps 608, 610and 612 evaluate the sequence. This loop is repeated for all thesequences to be evaluated and a final selection is made later at step616.

For the sequence selected at step 606, the expected switching time foreach railcar in the cuts is determined. The selected sequence is thesequence of cuts which may be cuts that are presently in the switchyardand await switching, cuts on the rehump tracks or cuts expected toarrive (enroute trains).

The computation of the expected switch time for a given railcar is anapproximation of the time at which the railcar is expected to beavailable for switching. Several factors can be used in making thisdetermination, for example:

-   -   a. The number of railcars that are presently in the hump        switchyard 10 and that are yet to be switched;    -   b. The rate or arrival of railcars in the switchyard;    -   c. The rate at which railcars are switched;    -   d. Resources available to prepare the railcars for switching.

Factor (a) and factor (b) allow determining, at any given time, how manyrailcars will be in the queue awaiting switching. Recall that thisinformation is readily available to the OM controller 46 from the SRScomponent 30. Factor (c) can be a rate computed on the basis of theoperations in the hump switchyard 10 that occurred in the past couple ofhours. For example, a railcar switching rate can be computed on thebasis of the number of railcars switched in a given time frame, say thelast two hours. A railcar switching rate can also be computedtheoretically by taking into account resources available (factor d) inthe switchyard to perform the operations necessary to prepare therailcars for switching. One such operation is the mechanical inspectionof the railcars. One such resource is the number of crews that canperform the preparation for switching, namely the mechanical inspection.By considering the average number of railcars that a crew canmechanically inspect it is possible to compute the rate at whichrailcars can be made available for switching. Another possibility is totake into account the rate computed on the basis of switching activitiesthat have occurred in the past previous hours and adjust it to take intoaccount variation in the number of crews, for instance increase thepredicted rate if the number of crews increases or decrease the rate iffewer crews will be available.

The OM controller 46 can, on the basis of the above factors, determinefor a given railcar, the number of railcars that precede it in thehumping queue. Then on the basis of the switching rate, an expectedswitching time for the railcar can be computed.

Note that the expected switching time for a given railcar is dependenton the particular switching sequence determined at step 604. As thesequence changes, the expected switching times for the railcars willchange since the railcars are switched in a different order.

In a specific example of implementation, the following rules are used tocompute an expected switch time for each railcar in the sequence:

-   -   1. The earliest expected switch time of a given cut is the        inspection end time+30 minutes for a cut in an available status,        expected inspection time+30 minutes for a cut in inspection or        waiting status or if the train is enroute. Note that for cuts in        waiting status the inspection start/end times will be based on        crew availability and for trains enroute these will be based on        crew availability as well as ETA.    -   2. The actual expected switching start time of the cut is the        greatest of the earliest expected switching start time of the        cut as calculated at 1 above and the expected switching end time        of the previous cut in the sequence. The expected switching end        time of the previous cut is computed on the basis of switching        rate parameter (number of railcars switched per hour). An        example of a switching rate parameter is 125 railcars/hour and        an example of inspection rate parameter is 60 railcars/hour per        crew based on two crews.    -   3. The expected switch time of each railcar is based on the        expected switching start time of the cut and the position of the        railcar in the cut and the switching rate.

After the expected switching time for each railcar of the sequence hasbeen computed, the process continues with step 610 where a scenariodeparture train is determined for each railcar. A scenario departuretrain is the earliest train with a cut-off time after the railcar'sexpected switch time that can carry the railcar's outbound block, andthe train has space for this railcar.

The assignment of a scenario departure train is an iterative process.The railcars are examined in the order of their expected switching time.A railcar is assigned to the earliest train in a set of candidatedeparture trains, which has a cut-off time after the railcar's expectedswitching time and that can carry the railcar's outbound block and thetrain has space for this railcar, in other words, the train and blockcapacities have not been exceeded.

Before assigning a scenario train to a railcar, first, candidatedeparture trains for that railcar are determined. A candidate departuretrain is any departure train that can carry the railcar's outbound blockas a core block or as a filler block and whose cut-off time is after therailcar's arrival time in the switchyard and the switchyard processingstandard, as discussed earlier. Obviously, a candidate departure trainalso takes into account the destination of the railcar. Departure trainsthat cannot carry the railcar to the intended destination are notconsidered. Also, departure trains that have a Scheduled Departure Time(SDT) that is before or after the objective departure train's SDT, canbe suitable candidate departure trains, hence they are considered whendetermining the scenario train. However, note that in this example, adeparture train that has an SDT that is before the SDT of the objectivetrain can be a suitable candidate departure train only when it can carrythe railcar in a filler block.

The set of candidate departure trains determined for each railcar may beaugmented to include departure trains that depart before the railcar'sarrival time plus the switchyard processing standard. This option may beuseful in instances where the railcar is processed earlier than theswitchyard standard and is able to connect to this train.

Before starting the iterative process, the remaining capacities of thecandidate departure trains (for all railcars) are initialized bysubtracting from the actual capacities the space taken up by railcarsalready processed and committed to the trains as per step 604 above.

The iterative process is a series of passes that consider all thecandidate departure trains and assign each railcar to a candidatedeparture train that becomes the scenario departure train for thatrailcar.

The iterative process starts with a first pass. As indicated earlier therailcars are examined in the order of their expected switching time. Inthis pass only those candidate departure trains that have a core blockfor a railcar are considered for assignment. For instance, consider thefirst railcar of the first cut in the sequence. This railcar isprocessed before any other railcar since it has the earliest expectedswitching time. The OM controller 46 that has previously identified thecandidate departure trains for that railcar will select the one thathas:

-   -   1. the earliest cut-off time after the expected switching time        of the railcar; and    -   2. has a core block for that railcar.

The selected train by the OM controller 46 is tentatively assigned tothe railcar as a scenario departure train and that departure train andblock remaining capacities are reduced by one.

Once the first pass is completed a second pass is initiated whichperforms a broader assessment and attempts to find space for the railcarin a departure train either in a core block or in a filler block. Thesecond pass processing first determines if there are any activatedfiller blocks on anyone of the candidate departure trains determined forthe railcar. If there are no activated filler blocks on anyone of thecandidate departure trains then the second pass is not required and thescenario departure train tentatively assigned to the railcar during thefirst pass is now confirmed as actual scenario departure train. On theother hand, if there are activated filler blocks on one or more of thecandidate departure trains, first a computation is done to assess thecapacity of the filler blocks. The capacity of a filler block iscomputed as the train's capacity minus the space taken up by all thecore block railcars assigned to this train, such as the railcarsassigned in the first pass. Note that if more than one filler block fora given candidate departure train has been activated, then the fillerblock capacity computed above is jointly shared by the several fillerblocks and it will be allocated on a First-In, First-Out (FIFO) basis.

The second pass implements a broader assessment because candidatedeparture trains that include both core and filler blocks are consideredfor assignment. A railcar will be assigned to the first eligible trainthat can carry the railcar, either in a core block or in a filler block(which implies that the train has sufficient remaining block and traincapacity). For example, in a case where a candidate departure train thatcan carry the railcar in a filler block but it has a cut-off time thatis after the cut-off time of the scenario departure train, then the OMcontroller 46 will retain the scenario departure train determined duringthe first pass. However, in an opposite case, where a candidatedeparture train with a filler block is available and it has a cut-offtime earlier than the cut-off time of the scenario departure traintentatively assigned during the first pass, then the tentative solutionis disregarded and the scenario departure train assigned to the railcarbecomes the one with the filler block. Once this assignment is made, thetrain capacities are adjusted. The adjustment includes:

-   -   1. reducing the filler block capacity of the newly assigned        scenario departure train by one;    -   2. reducing the train capacity of the newly assigned scenario        train by one;    -   3. increasing the core block capacity of the previously        tentatively assigned scenario departure train by one (to negate        the previous capacity reduction); and    -   4. increasing the train capacity of the previously tentatively        assigned scenario departure train by one (to negate the previous        capacity reduction).

In certain cases a third pass may also be required. For instance,consider the situation where a train TA has a filler block for block Band train TB has a core block for block B and TA departs before TB. Nowlet's say there is a block C for which the core block is on train TC anda filler block on train TB and TB departs before TC. In such situation,a block B railcar may shift to train TA and thus release capacity on TB.If block C railcars are overflowing TC then they should be shiftedforward to TB. For this reason a third pass may be desirable.

In general, the process may benefit from as many additional instances ofthe third passes as the length of the chain of blocks connected in theway described above, minus one. For instance, if there is a chain ofthree blocks linked in this way the third pass may need to be repeatedtwice.

Note that before any instance of the third pass is initiated thecapacities of the filler blocks should be updated. This is done byexamining the solution from the previous pass as follows:

-   -   1. Check for the following three conditions:        -   a. There is a train T which has unused train capacity and            has an activated filler block for block B;        -   b. The filler block is at capacity;        -   c. Some railcars of block B are assigned to a train that            departs after train T (because block B on train T is full);    -   2. If the conditions under 1 are met then:        -   a. New capacity of the filler block on train T is equal to            the capacity of the filler block in the previous pass plus            the unused capacity of train T.

Finally, a check is performed for a last pass. If at the end of aninstance of the third pass the three conditions described above under 1are met then another instance may be necessary, otherwise not.

Note that even if three conditions are met, it may happen that norailcar that has been assigned to a later train can shift up to anearlier train (which was underutilized in the previous pass instance)due to expected switching time constraints. In this case there will beno change in train length from one pass to the next. If this conditionis verified then no more instances of the third pass are made.

The above-described process is repeated for every railcar in thesequence generated at step 606. So, when step 610 is completed, the OMcontroller 46 produces a list that associates each railcar with a givenscenario train, as well as the candidate trains and their respectivecapacities. This list will be used in the next step to compute a score.

Step 612 follows step 610 and computes for each railcar a score that isused as a basis to rank the various switching sequences. Morespecifically, step 612 applies scoring rules based on the objectivetrain, the scenario train and the candidate trains for the railcar.Below is a possible example of scoring rules:

-   -   1. If the scenario train is the objective train(successful        connection is expected), score=+1;    -   2. If the scenario train's SDT is before the objective train's        SDT, score=+1;    -   3. If the scenario train's SDT is after the objective train's        SDT, and any candidate departure train departs before the        scenario train is expected to be under capacity, score=−1;    -   4. If the scenario train's SDT is after the objective train's        SDT, and all candidate trains departing before the scenario        train are full, score=0. However, if the scenario train is        scheduled to depart within 12 hours after the objective train        then the score is=+0.5.

Step 612 computes a score for each railcar using the above rules. Itshould be expressly noted that those rules are mere examples anddifferent rules can be implemented without departing from the spirit ofthe invention.

The step 612 completes by computing a collective score for the sequencegenerated at step 606. The collective score is the sum of the individualscores of the railcars making up the entire sequence. In this example,the collective score expresses the performance status of the switchyard10 that would be reached should the railcar sequence be run.

Step 614 is a decision step. If the sequence processed last is the lastsequence, in other words step 606 cannot generate any other differentsequence, then step 614 is answered in the negative and the processcontinues at step 616. Otherwise the processing returns to step 606where a new sequence is generated and processed by steps 608, 610 and612 as discussed earlier. This continues until all the sequences havebeen exhausted.

Step 616 compares the collective scores for all the sequences andselects the preferred one. In this particular example, the preferredsequence is the one that has the highest collective score. In otherwords, the preferred sequence is the one that would put the switchyardin the highest performance status. In the event there is a tie, apossible approach is to select the sequence that has the lowest numberof missing connections for certain railcars, for example loaded railcarsversus empty railcars. Another possible approach to break the tie is toselect a sequence among the sequences that are tied that is closest tothe current sequence, so as to deviate least from the current yard workplan. Again, the reader will appreciate that other factors can be reliedupon in selecting a sequence in the event of a tie, as missed connectionor similarity to the current sequence are only examples of metrics thatcan be used.

The above example of implementation uses a computational method thatevaluates all the possible sequences in a given number of cuts. For someapplications, in particular those where the number of cuts to evaluateexceeds 10, the computational requirements become significant since thenumber of possible sequences grows to large numbers. In this casevariants can be implemented to reduce the computational complexity. Onesuch variant is the so called “Strong Optimality” (SO) property that canbe used to limit the number of sequences that need to be considered.Assume for the sake of this example that sequences of 10 cuts need to beevaluated. An evaluation method based on the SO property does not lookonly at complete sequences of the 10 cuts. Rather, the method builds upfrom smaller sub-sequences (a sequence of a subset of the 10 cuts) andreduces the search space through evaluation of these sub-sequences.

For the purpose of this example, a sequence is considered StronglyOptimal (SO) if it has the highest score of all other sequences of thesame cuts and its hump completion times is not greater than that of anyother sequence.

Consider the following example:

If the method is to evaluate 5 cuts—Cut Nos. 1, 2, 4, 6 and 7, there are5!=120 possible sequences. Let's say S(1,6,4,2,7) is the score ofsequence 1,6,4,2,7, and T(1,6,4,2,7) is its completion time. If1,6,4,2,7 is an SO sequence then for any other sequence, say 1,2,4,6,7,S(1,6,4,2,7) is >=S(1,2,4,6,7) and T(1,6,4,2,7)<=T{1,2,4,6,7).

The SO property implies that an extended sequence derived from an SOsequence will be superior to a similar extension of any other sequence.That is, in the above case the sequence 1,6,4,2,7,N will be better thanthe sequence 1,2,4,6,7,N in terms of score whatever the cut N is.

A point to note is that the SO sequence may not be unique (a tiesituation). There can be two or more sequences with the same highestscore. In that case a possible approach is to arbitrarily choose one ofthose SO sequences for further consideration and neglect the remainingones, or use anyone of the solutions discussed earlier for breaking thetie.

In some cases a possibility may arise that an SO sequence does not existfor a subset of the cuts. In that situation two or more non-StronglyOptimal or NSO sequences will be in existence.

Using the same example as above:

Let's say 1,6,4,2,7 is the sequence with the highest score but itscompletion time is longer than that of another sequence. That is,S(1,6,4,2,7)>S(1,2,4,6,7) but T(1,6,4,2,7)>T(1,2,4,6,7). Then both1,6,4,2,7 and 1,2,4,6,7 are NSO sequences. In this case it cannot besaid that the score of the extended sequence 1,6,4,2,7,N is greater thanthat of 1,2,4,6,7,N because the hump start time of cut N in the lattercase may be earlier. This could avoid some missed connections andincrease the additional score associated with the cut N.

When a subset of cuts does not have an SO sequence a set of NSOsequences can be identified such that all other sequences not in thisset have both a lower score and a longer completion time than any of theNSO sequences. The number of NSO sequences may be quite large (in theextreme case all possible sequences of a subset of cuts may be NSO).

In order to enhance optimality it has been found advantageous to keeptrack of all the NSO sequences as the process builds upon them. Aslonger sequences are being built, the set of NSO sequences can expand orcontract. However, in order to limit the computation one possible optionis to keep no more than say, 3 NSO sequences for any subset of the cutsbeing considered, realizing that this may cause some loss of optimality.The choice of the number to keep is a trade-off between computationspeed and solution quality.

The process under this variant generates and evaluates sub-sequences initerations rather than generating complete sequences as in the completeenumeration technique described earlier. It starts by looking atsequences of length 2 in the first iteration, then in the seconditeration it looks at sequences of length 3, and so on. One possibleimplementation is to consider, at most, 10 workloads/cuts foroptimization (that is, if the switchyard operator has fixed the humpsequence of the first 3 cuts, say, then the OM controller will determinethe best sequence for the cuts numbered 4 through 13).

The sequence generation is described below for the simple case where theSO property holds for every subset of cuts.

1. First Iteration

-   -   In the first iteration all 2-cut sequences are examined to        determine the SO sequence for each 2-cut combination.    -   The number of 2-cut combinations is 10C2=(10*9)/(1*2)=45.    -   For each combination all possible sequences are evaluated. For        example, for the combination [3, 5] the cost and time of the two        possible sequences 3, 5 and 5, 3 is calculated. Let's say the        sequence 5, 3 is SO. It is kept as a candidate. The sequence 3,        5 need no longer be considered.    -   At the end of the first iteration an SO sequence will be        available for each of the 45 2-cut combinations together with        its cost and time.

2. Second Iteration

-   -   In the second iteration 3-cut combinations are evaluated. This        is done by extending the SO sequences of the 2-cut combinations        determined in the previous iteration and evaluating them to        determine the SO sequence for each 3-cut combination.    -   The number of 3-cut combinations is 10C3=(10*9*8)/(1*2*3)=120.    -   For any given combination the following process is implemented.        Let's say the combination [1,3,5] is being considered. By virtue        of the SO property only the SO sequence of [1,3] needs to be        evaluated, extended by cut number 5, the SO sequence of [1,5]        extended by cut number 3, and the SO sequence of [3,5] (which        happens to be the sequence 5,3) extended by cut number 1. The        best of these three extended sequences is the SO sequence of        cuts [1,3,5].    -   Thus only 3 sub-sequences need to be computed and compared to        determine the SO sequence for each 3-cut combination.    -   At the end of the second iteration an SO sequence will be        available for each of the 120 3-cut combinations together with        its cost and time.

3. Subsequent Iterations

-   -   The subsequent iterations follow a similar pattern. In the kth        iteration 10C(k+1) combinations of length k+1 will exist and for        each combination one needs to calculate and compare k+1 extended        sub-sequences (derived from the SO sequences of the previous        iteration).

4. Ninth and Last Iteration

-   -   At the end of the 8th iteration 10C9=10 SO sequences of length 9        are in existence. The process needs to calculate and compare 10        extensions i.e. extend each of the 10 SO sequences of length 9        by the remaining cut in order to obtain the optimal sequence of        all 10 cuts.

5. Case with NSO Sequences

-   -   The method described above is essentially the same even when for        a particular combination of cuts there is no SO sequence. The        process then keeps all (and in this specific example at most 3)        NSO sequences associated with this combination. In the next        iteration this will increase the number of calculations and        comparisons accordingly. However, at the end of the next        iteration it is possible for the number of NSO sequences to        increase or to decrease.

FIG. 7 illustrates an optional enhancement to the OM controller 46. Theoptional enhancement is an outbound workflow forecasting module whichprovides a user, such as the yard master, with a view of departuretrains that the switchyard is to build. In this example, the workflowforecasting module creates a projection of what the departure trainswill look like, based on the predicted workflow. The predicted workflowis the railcar traffic that the switchyard is processing and optionallyrailcar traffic that the switchyard will process in a short while. In aspecific example, the railcar traffic information that is used togenerate the outbound workload forecast includes railcars that are yetto be switched into classification tracks, such as railcars presently inthe switchyard (and that may be currently in the initial switchyardprocessing stages) and also railcars that have not yet arrived in theswitchyard but for which an Estimated Time of Arrival (ETA) exists.

The outbound workflow forecasting module is software implemented andgenerates a series of views that show to the user information pertainingto the railcar traffic that will be available to scheduled departuretrains for transport out of the switchyard. Certain safeguards are alsoincluded in the system to show when the available railcar trafficexceeds the capacity of departure train, allowing the user to manuallyadjust settings to correct the situation.

In FIG. 7, the outbound workflow forecasting module is shown by thereference numeral 700. The outbound workflow forecasting module receivesas input information relating to railcar traffic for processing by theswitchyard. As indicated earlier, the railcar traffic includes railcarsthat have arrived in the switchyard and optionally railcars that are yetto arrive in the switchyard. In a specific example of implementation,this information is conveyed by the objective train information and thescenario train information computed for each rail railcar, as discussedearlier in this specification. In other words, the outbound work flowforecasting module 700 receives for each railcar of the pool of railcarsthat constitutes the railcar traffic, the computed objective traininformation and scenario train information.

In addition, the outbound workflow forecasting module also receivesinformation from SRS about the departure trains, such as theidentification of each train, the estimated time of departure of eachtrain and the train blocks making up the trains. The information that isavailable from SRS is discussed earlier in the specification.

The information that is output by the outbound workflow module 700 isconveyed to the user interface 53. In the specific example ofimplementation, the user interface includes a display on which theinformation is shown to the user. The user interface also includesinputs, which allow the switchyard operator to input data in theoutbound workflow forecasting module 700, as it will be discussed below.

The process performed by the outbound workflow module on the informationthat is input into it is depicted by the process shown at FIG. 8. Theprocess starts at step 800 and computes for every departure train aforecast of the railcar traffic that will be available to that train fortransport out of the switchyard. In the specific example illustrated bythe process of FIG. 8, the forecast of the railcar traffic includes twocomponents, one being a rough projection of the railcar traffic and onebeing a more refined and accurate projection of the railcar traffic.

The rough projection, referred to as “traffic offered”, is computed atsteps 802 and 804. Specifically, the objective train information foreach railcar in the switchyard (including those on incoming trains) forwhich this parameter is computed is classified per train block andsubsequently per train to which the railcars belong. The purpose is toobtain a rough projection valid at the ETD of every departure train, ofthe railcars that will be available for pick-up by that train. This isshown by processing step 804. Traffic offered could be from variouslocations, namely en route trains, receiving tracks of the switchyard,classification tracks of the switchyard or departing tracks of theswitchyard. To include a railcar in the traffic offered in connectionwith a particular departure train, the objective train of that railcarshould be that particular departure train.

Note that the traffic offered is not static and changes as the objectivetrain information changes. As the objective train may be periodicallyrecomputed, the objective train may change over time. This change willhave an impact on the traffic offered. Accordingly, the projection oftraffic that will be available to departure trains will change asrailcars are being processed by the switchyard. Those changes will begreatest for departure trains having the furthest ETD. This is becausethe traffic offered projection is based on objective train computationsfor railcars that are in the early switchyard processing stages or havenot yet arrived and for those railcars the objective train computationscan change. In contrast, as the railcars progress through theswitchyard, in particular as the railcars are switched and classified,the objective train information is much less likely to be changed.Therefore, as the EDT for a given train approaches the current time, thetraffic offered projection progressively firms up to a point where it isfixed and no longer changes.

The refined projection of the railcar traffic, referred to as “consistforecast” is computed at steps 807 and 806. Specifically At step 807 thescenario train information is processed to generate at step 806 theconsist forecast. The consist forecast would typically be a subset ofthe traffic offered and it is generated on the basis of the scenariotrain information input into the outbound work flow forecasting module700. Typically, the processing step 807 will examine all the railcars inthe group of railcars that constitute the traffic offered for thepresent departure train to extract those having a scenario train whichmatches the present departure train. Recall that the objective train fora railcar is, in the specific examples provided earlier, a connectionstandard computed on the basis of the time of arrival of the railcar towhich is added a certain time processing standard. In contrast, thescenario train, in the examples provided earlier is a refined version ofthe objective train that takes into account the various processes takingplace in the switchyard. For instance, the scenario train of a railcarmay change depending on the computed switching sequence for thatrailcar. Accordingly, the consist forecast is a more accurate projectionof the railcar traffic that will be available to the departure train.

In addition, the processing at step 807 also determines if the consistforecast established on the basis of the scenario train information willfit the capacity of the departure train. Several capacity limits can beconsidered, namely train length limit, train weight limit or number ofrailcars limit. If any of those limits is exceeded, a message isproduced to advise the user. The limits applicable to a given departuretrain can be input into the system in different fashions. For instancethis information can be associated with the train object describing thedeparture train, manually input by the user or inferred depending onparticular conditions, such as for example the specific departure trackthe train occupies. The departure track may be limited in length and,therefore accept a limited number of railcars. This limit condition onlyapplies to departure trains that occupy that particular departure track;longer departure tracks will not have those limits. Also, there may beinstances where access to motive power is limited and thus the departuretrain may be assigned fewer locomotives than the projected trafficoffered requires. In such instances, a weight limit will be enforced anda message will be issued to the switchyard operator to indicate that alimit has been exceeded and also to indicate the maximal train weightpermissible for the available motive power.

Corrective action that may be taken when the consist forecast computedon the basis of the scenario train information exceeds the capacity of adeparture train can be manual or automatic. A manual corrective actionwill normally require the user to specify what corrective action is tobe implemented by entering commands via the user interface 53.Specifically, the user may chose to close one or more train blocksearlier such as to limit the number of railcars in the departure train.The choice of the blocks to close earlier is left to the discretion ofthe user. An automatic corrective action may also be considered wheretrain blocks are closed in a random fashion or by applying any suitablelogic rules.

Once a corrective action has been input into the system, which isdepicted in FIG. 8 by the arrow 805, an update on the scenario traininformation for the railcars that are left behind, and those that areupstream in the switchyard processing is performed. A new computation iseffected, as discussed earlier, this time taking into account that thedeparture train to which railcars where previously allocated, is nolonger available. Most likely the new scenario train selected for therailcars will be the next departure train (for the correct destination)or a subsequent departure train. Note that the update may trigger aripple effect, since the re-allocation of railcars to a new train mayremove space that was reserved for other railcars, which in turn mayneed to be pushed back to yet another departure train. Since the OMcontroller 46 is designed to constantly re-compute the scenario trainfor railcars, in particular those that are yet to be switched, changesresulting from corrective actions described above can be in generalquite easy to accommodate.

As the new scenario train for the railcars left behind is computed, theconsist forecast computed on the basis of the scenario train informationwill change to reflect the fact that the railcars are now planned to bepart of a subsequent departure train.

The corrective actions and the subsequent adjustments to the trafficoffered occur in most instances before the departure train is beingbuilt. Accordingly, the forecasting operation not only allows to “view”what departure trains will look like but also to proactively adjust thetrains composition such that they fit existing limits.

The information produced by the outbound workflow forecasting module 700is displayed to the user via the user interface 53. This is also shownat step 808 in FIG. 8. FIGS. 9 to 17 illustrate are examples of screenviews that show the manner in which the information is presented and thevarious commands that are available to the user.

FIG. 9 is the outbound Line Up screen used to monitor the processesleading up to the departure of all trains. It helps manage the flow ofrailcars to outbound trains and the identification of the candidatetraffic that will make those trains. Through that screen, the user alsohas access to other screens to manage individual outbound trains.

The following columns of information are displayed on the main grid:

-   -   Outbound departure trains: The train ids departing the station        (i.e. M 30131-15)    -   STD: Train Schedule departure time    -   ETD: Adjusted scheduled departure time    -   Status: The stage of the process in which the cut is    -   Departing Track: The outbound track identifier (i.e. W001)    -   Multiple Outbound tracks: Identified by a “+” when more than one        outbound track is used to build the train. This field expands to        display all the departing tracks used and the actual status of        the tracks    -   Traffic Offered: Number of railcars, feet and tonnage to be        available to the outbound train within yard connection standards    -   Consist Forecast: Number of railcars, feet and tonnage projected        to make the train    -   Last railcar: The time at which the last railcar included in the        forecast will be processed. This column will also display as a        tool tip the actual time at which the last railcar was processed

The table can be sorted by Schedule Departure time (STD), EstimatedDeparture time (ETD) or Train ID.

The table can be filtered to show train departure by yard area.

From the screen in FIG. 9, the traffic details for an outbound train canbe viewed by clicking on the appropriate Train ID. This will lead to thescreen shown in FIG. 10,

The user can do outbound management (adjust the train block, add a fillblock, close the block, set the block footage and change the train blockcut-off to correct overflow situations). This will be described inconnection with FIGS. 14 and 15.

The outbound railcar traffic that will make up the train will beforecasted automatically by the system, as discussed earlier. The usercan also manually forecast the traffic that will make up the departuretrain via the Train details screen to generate an outbound forecast, asdiscussed in connection with FIGS. 16 and 17.

The following rules are applied in connection with the variousparameters presented in FIG. 9:

-   -   Scheduled/Estimated Train Departure (ETD): In a specific        example, if the ETD is within 29 minutes of the STD the        background color of the ETD is neutral, if it is between 30 and        59 minutes late the background is YELLOW and if the ETD is 60        minutes or more late it is RED. If the ETD is in the past, the        background should turn BLUE.    -   Status parameter: Initially, an outbound train has a status of        “Planned”. When the outbound train is ready to be built the        status changes to “Pull Down”. Once the pull down is complete or        a track is available for inspection, the train or track (via        expandable departing track column) is changed to “Set” outbound        inspection. When the mechanical group starts inspecting the        outbound train the status is changed to “Inspection”. Once the        inspection is complete, the train is changed to “Departing”        status indicating that the train is ready to depart as soon as        power and crew are in position.    -   Traffic Offered parameter: This section of the table shows the        rough volume of railcar traffic that is projected to be        available in time for the outbound train according to yard        connection standards—that is, the railcars where the objective        train id equals the outbound train. Fill block traffic is not        counted in the offered count, as long as it is not included        specifically by the user. If the volume of traffic offered        exceeds the capacity of the outbound train, the footage and/or        tonnage number is highlighted with a RED background. This        message prompts the user to specify block restrictions to shape        what traffic will actually be handled on the departure train,        and to make alternative plans for the traffic that cannot fit.        If alternative plans are made to move part of the traffic early        (e.g. a fill block on an earlier train), the traffic offered is        increased for the train that receives the early traffic, and        remains unchanged for the original objective train.    -   Consist Forecast parameter: This section of the table shows a        more refined volume of railcar traffic that is projected to be        available in time for the outbound train according to scenario        train computations. It is possible that the consist forecast as        computed on the basis of the scenario train exceeds the capacity        of the outbound train in terms of footage, or other. When this        happens the forecast shown will be a subset of the computed        consist forecasts, taking into consideration the hump plan, the        capacity of the outbound train, block restrictions, and        alternative plans made to handle the overflow. As the hump plan        changes (as a result of changes in priority, hump rate, inbound        inspection performance, and/or traffic volume) the outbound        projections automatically adjust. As the departure time        approaches, the accuracy of the forecast increases. Once the        train cut-off time has passed, these numbers should normally be        static.    -   Last railcar parameter: This is the time that the last railcar        in the consist forecast (Scenario Train ID=Outbound Train) will        be processed and, therefore, available for the outbound train.        This information can be used to plan early pull downs, and is        also useful for monitoring the impact of the departure time on        dwell. If the last railcar is always available well before the        scheduled departure, it could create a network opportunity to        advance the scheduled departure. If the last railcar is        available, the Last railcar column displays “Now” with the        background of this field in GREEN. The actual time at which the        last railcar associated to this train (=Scenario Train ID) was        processed is also displayed as a tool tip.

The train details screen, shown in FIG. 10 is used to monitor thecontent of specific outbound trains. It shows a train's core and fillblock information down to the railcar level. Each detail level providesinformation to qualify the train's system-generated consist forecast.The user can then use this information to generate a manual forecast.

The columns displayed in the train details screen are:

Top Grid (For train blocks)

-   -   Trn Block: The train blocks defined for that specific train, not        editable.    -   Incl: This block is included in the outbound forecast (Yes or        No, defaulted to Yes for core blocks and to No for fill Blocks),        editable field.    -   Cut-Off: The cut-off for a block (defaulted to the train's one),        editable field.    -   Limits (Ft): Restriction on the block length (normally blank),        editable field.    -   Offered, Processed and Consist Forecast railcars: Number of        railcars for the train block (loaded or empty) that are offered,        processed or forecasted for the selected train id, not editable.    -   Offered, Processed and Consist Forecast Ft: The total railcar        feet of all railcars for the train block that is offered,        available or forecasted for the selected train id, not editable.    -   Offered, Processed and Consist Forecast Tons: The total gross        tons of all the railcars for the train block that is offered,        available or forecasted for the selected train id, not editable.        Offered, Processed and Consist Forecast Totals: The summation of        the railcar number, feet and tons for the train block that is        offered, available or forecasted for the selected train id is        displayed at the bottom of each column, not editable.    -   Manual Forecast Total: The summation of the traffic selected        manually by the user, editable field.    -   Bottom Grid (for filler blocks): The same columns are displayed        as for the core blocks

The user can expand a specific train block from the screen in FIG. 10 tothe Track/Train level, shown in FIG. 11, by selecting the desired block.The columns displayed in the Track/Train level section in FIG. 11 are:

-   -   Track/Train: The current location of the group of offered        railcars for the selected block (Track or Train).    -   Process Time: The time at which the last railcar in the group        will be made available (its classification time). If the group        of railcars is available for the outbound train        (classified/processed), this field shows NOW. It otherwise        indicates the estimated time the last railcar of the track is        going to be processed.    -   To Track: The target track of the group of offered railcars for        the selected block.    -   Offered, Processed and Consist Forecast railcars: Number of        railcars for the block's track (loaded or empty) that are        offered, processed or forecasted for the selected block.    -   Offered, Processed and Consist Forecast Ft: The total railcar        feet of all railcars for the block's track that is offered,        available or forecasted for the selected block.    -   Offered, Processed and Consist Forecast Tons: The total gross        tons of all the railcars for the block's track that is offered,        available or forecasted for the selected block.

The user can expand a specific train to the location level by selectingthe desired train. This is shown in FIG. 12. The columns displayed inthe location level section are:

-   -   Location: The location of all railcars on the train or scheduled        to be picked up by the train    -   Offered, Processed and Consist Forecast railcars: Number of        railcars for the block's track (loaded or empty) that are        offered, processed or forecasted for the selected block.    -   Offered, Processed and Consist Forecast Ft: The total railcar        feet of all railcars for the block's track that is offered,        available or forecasted for the selected block.    -   Offered, Processed and Consist Forecast Tons: The total gross        tons of all the railcars for the block's track which is offered,        available or forecasted for the selected block.

The user can expand a specific location to the railcar level byselecting the desired Location. Alternatively, for tracks at thetrack/train level, the user can go directly to the railcar Level byselection the desired Track. The columns displayed in the location levelsection shown at FIGS. 13A and 13B are:

-   -   Car Initial    -   Car Number    -   L/E: Load/Empty    -   Feet: railcar length in feet    -   Tons: railcar weight in tons    -   Car Kind    -   Contents: railcar contents

The following rules are applied in connection with the screens shown inFIGS. 10 to 13A and 13B.

-   -   Block fields: Sorted in train block sequence order (for        outbound). The front-end block is displayed at the top row.    -   Incl field: If set to Yes, the train block will be included into        the outbound train forecast according to its limitations and the        train capacity. If set to No, the train block won't be included        in the consist forecast.    -   Cut-off: Can be adjusted by the user. Not displayed if the block        is not included (Incl.=N).    -   Limits: Can be set by the user. Blank if no limit was entered.    -   Processed: Traffic Offered already switched that qualifies to be        moved on the selected departure train ID. Traffic processed can        be from classification tracks, departure tracks, or receiving        tracks in outbound status.    -   Consist Forecast: traffic offered included to be part of the        outbound train based on the restriction set by the system        (default) or by the user, until the Spec limit of the train is        reached. Traffic is evaluated by switch time. To qualify, a        railcar's scenario train should be the designated as the        particular departure train.    -   If the Consist Forecast volume for a block is less than offered,        that block is highlighted. This indicates that some of the        traffic offered for the block will have to be left behind due to        a capacity constraint.    -   Manual Forecast: Is equal to the consist forecast as long as no        manual forecast has been built.

Now, with reference to FIG. 14, the user can modify a train'ssystem-generated forecast by adjusting block settings on the TrainDetails screen (FIG. 14). More precisely, the user can decide to includeor exclude blocks (Fill or Core), adjust a block's cut-off time, andmodify or set footage limitations on the train and its constituentblocks. Specifically, on the train details screen (FIG. 14), thefollowing fields are editable at the block level only:

-   -   Incl: This block is included in the Consist Forecast (Yes or No        defaulted to Yes for core blocks and to No for fill blocks).    -   Cut-off: The cut-off for a block (defaulted to the train's one).    -   Limits Feet: Restriction on the block length (normally blank).    -   Spec Limit: Value can be changed manually at the train level.

A calculator selection (new column in FIG. 15) is also available to setthe block Limit. This calculator allows for selecting traffic down tothe railcar level.

The following rules are applied in connection with the screens shown inFIGS. 14 and 15.

-   -   Cut-Off: Modification to the cut-off will affect the train        assignment process. A change in cut-off will affect railcars        that have not yet been processed. Normally, as the cut-off is        pushed to a later time, more railcars will be included in the        traffic offered and consist forecast due to a re-assignment of        their scenario Train to the current outbound train. Conversely,        if the cut-off is moved to an earlier time, railcars scheduled        to be processed after the cut-off will be removed from the        consist forecast but not from the traffic offered since their        objective train is not impacted. The user can update the cut-off        to any time from now to ETD.    -   Limits (Ft): If not blank, this value limits the block's consist        forecast (Cars, Feet, and Tons) through the footage. The block        will only be restricted to respect the train limit otherwise.        Since a train block can have a core portion and a fill portion,        limits can be set for these portions separately.

Although various embodiments have been illustrated, this was for thepurpose of describing, but not limiting, the invention. Variousmodifications will become apparent to those skilled in the art and arewithin the scope of this invention, which is defined more particularlyby the attached claims.

1. A system for forecasting the outbound workload in a switchyard havinga switch, said system comprising: a. a data processing entity includinga CPU and a machine readable storage encoded with software for executionby the CPU, the data processing entity: i. processing railcar dataconveying information on individual railcars yet to be switched by theswitch, the railcars having respective destinations outside of theswitchyard; ii. computing for the railcars respective approximate timesindicating when the railcars are expected to be available for pickup bya departure train; iii. associating the railcars to respective departuretrains, the departure trains being characterized by respective estimateddeparture times (EDTs) and destinations, the associating including: 1.comparing the respective approximate times with the EDTs of thedeparture trains;
 2. selecting for each railcar a departure train on thebasis of the comparing and that also has a destination that correspondswith the destination of the railcar; iv. generating for at least one ofthe departure trains a railcar traffic forecast data identifying one ormore of the railcars associated to the at least one departure train; andb. the data processing entity having an output for releasing theforecast data.
 2. A system as defined in claim 1, including a userinterface coupled to the output for communicating the railcar trafficforecast to a user.
 3. A system as defined in claim 2, wherein therailcar traffic forecast includes railcars that have arrived in theswitchyard and railcars inbound for the switchyard and yet to arrive atthe switchyard.
 4. A system for forecasting the outbound workload in aswitchyard including a switch and classification tracks, said systemcomprising: a) a data processing entity including a CPU and a machinereadable storage encoded with software for execution by the CPU, for: i)processing with the input data conveying information about railcars thathave not yet been switched into classification tracks of for assigningthe railcars to respective departure trains; ii) computing with thesoftware a forecast of railcar traffic that will be available toindividual ones of the departure trains for transport out of theswitchyard at least in part on the basis of said assigning, the forecastof railcar traffic in connection with a particular one of the departuretrains including an identification of one or more of the railcarsassigned to the particular one of the departure trains; b) an output forreleasing output data describing the computed forecast of railcartraffic available for at least one of the departure trains.
 5. A systemas defined in claim 4, wherein said software determines prior toassigning a railcar to a particular departure train if space isavailable for the railcar in the particular departure train.
 6. A systemas defined in claim 2, wherein said user interface includes a GUI.
 7. Asystem as defined in claim 6, wherein said GUI includes an informationfield displaying to a user an EDT of the at least one departure train.8. A system as defined in claim 6, wherein said GUI includes aninformation field displaying to a user current status information of theat least one departure train.
 9. A system as defined in claim 8, whereinthe current status information distinguishes between a departing statusassociated with a departure train that is ready to depart and aninspection status associated with a departure train undergoinginspection.
 10. A system as defined in claim 8, wherein the currentstatus information distinguishes between a departing status associatedwith a departure train that is departing and a planned status associatedwith departure train that is planned to be build.
 11. A system asdefined in claim 6, wherein said GUI includes an information fielddisplaying to a user a departure track of the switchyard in which the atleast one departure train is located.
 12. A system as defined in claim6, wherein said GUI includes an information field displaying to a userthe number of railcars associated with the at least one departure train.13. A system as defined in claim 6, wherein said GUI includes aninformation field displaying to a user the railcar traffic forecast datain terms of length of consist.
 14. A system as defined in claim 6,wherein said GUI includes an information field displaying to a user therailcar traffic forecast data in terms of weight of consist.
 15. Asystem as defined in claim 6, wherein said GUI includes an informationfield displaying to a user train block information conveyed by therailcar traffic forecast data train blocks.
 16. A system as defined inclaim 15, wherein the train block information conveys information aboutcore blocks.
 17. A system as defined in claim 15, wherein the trainblock information conveys information about filler blocks.
 18. A systemas defined in claim 15, wherein said GUI includes an information fielddisplaying for at least one train blocks, the number of railcars in athe train block.
 19. A system as defined in claim 15, wherein said GUIincludes an information field displaying for at least one blocks, thelength of the train block.
 20. A system as defined in claim 15, whereinsaid GUI is displaying for at least one train blocks, the weight of thetrain block.
 21. A system as defined in claim 2, wherein said softwaredetermines if the railcar traffic forecast data for the at least onedeparture trains makes reference to a volume of railcars for transportout of the switchyard that would exceed a capacity of the at least onedeparture train.
 22. A system as defined in claim 21, wherein if thevolume of railcars would exceed a capacity of the at least one departuretrain, said data processing entity generating an alert to the user viasaid output.
 23. A system as defined in claim 5, wherein said softwaredoes not assign the railcar to the particular departure train if thereis not sufficient space for the railcar on the particular departuretrain.
 24. A system as defined in claim 4, wherein said softwareperforms a computation to forecast when a processing performed by theswitchyard in connection with a railcar will be completed in assigningthe railcar to a particular departure train.
 25. A system as defined inclaim 24, wherein the computation includes determining an expectedswitching time for the railcar.
 26. A system as defined in claim 4,including a user interface connected to the output for communicating thetraffic available for the particular departure trains to a user.
 27. Asystem as defined in claim 4, wherein said assigning includes assigningto respective departure trains railcars that have arrived in theswitchyard and railcars inbound for the switchyard and yet to arrive atthe switchyard.
 28. A system as defined in claim 27, wherein eachdeparture trains is characterized by a scheduled departure time.
 29. Asystem as defined in claim 27, wherein said user interface includes aGUI.
 30. A system as defined in claim 29, wherein said GUI includes aninformation field displaying to a user a scheduled departure time of theparticular departure trains.
 31. A system as defined in claim 29,wherein said GUI includes an information field displaying to a usercurrent status information of the particular departure trains.
 32. Asystem as defined in claim 31, wherein said GUI includes an informationfield displaying to a user a departure track of the switchyard in whicha the particular departure trains is located.
 33. A system as defined inclaim 29, wherein said GUI includes an information field displaying to auser the forecast of railcar traffic that would be available for theparticular departure train, in terms of number of railcars.
 34. A systemas defined in claim 29, wherein said GUI includes an information fielddisplaying to a user the forecast of railcar traffic that would beavailable for the particular departure train, in terms of length ofconsist.
 35. A system as defined in claim 29, wherein said GUI includesan information field displaying to a user the forecast of railcartraffic that would be available for the particular departure train, interms of weight of consist.
 36. A system as defined in claim 29, whereinsaid GUI includes an information field displaying to a user the railcartraffic available for the particular departure train, broken down intrain blocks.
 37. A system as defined in claim 36, wherein said trainblocks include core blocks.
 38. A system as defined in claim 36, whereinsaid train blocks include filler blocks.
 39. A system as defined inclaim 36, wherein said GUI is displaying for at least one of said trainblocks, the number of railcars in a train block.
 40. A system as definedin claim 36, wherein said GUI is displaying for at least one of saidtrain blocks, the length of a train block.
 41. A system as defined inclaim 36, wherein said GUI is displaying for at least one of said trainblocks, the weight of a train block.
 42. A system for forecasting theoutbound workload in a switchyard including a switch and classificationtracks, said system comprising: a) a data processing entity including aCPU and a machine readable storage encoded with software for executionby the CPU, for: i) processing with the software data conveyinginformation about railcars yet to be switched in the switchyard, formatching the railcars to departure trains, said matching includingforecasting for a railcar the departure train that will be available totransport the railcar out of the switchyard when a processing of therailcar by the switchyard will be completed; ii) computing with thesoftware a forecast of railcar traffic that will be available toindividual ones of the departure trains for transport out of theswitchyard at least in part on the basis of said matching, the forecastof railcar traffic in connection with a particular one of the departuretrains including an identification of one or more of the railcarsassigned to the particular departure train; b) the data processingentity including an output for releasing data describing the computedforecast of railcar traffic available for at least one of the departuretrains.